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This document is directed to data processing professionals and their management. Its 
purpose is to demonstrate, through examples, both the simplicity and the power of 
SQL/DS. 
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Introduction 


As the demands on the data processing department continue to increase, many installa- 
tions are re-examining their traditional approaches to application development in order 
to keep pace with the rapidly growing backlog of applications. 


For some installations, this has meant providing their data processing professionals with 
additional tools so that they can become more productive. Other installations have cre- 
ated a new functional organization within data processing, called an Information Center, 
to provide and support a set of end-user tools. This allows the person with minimal DP 
skills to develop his own applications with a minimum of dependence on the DP 
department. 


In either case, new technologies in hardware and software have created an application 
development environment with significantly different characteristics than in the past. 
Installations have begun to focus on those aspects of application development from which 
they can achieve significant productivity gains by effectively using machine resources to 
augment people time—either by increasing the ongoing rate of traditional program devel- 
opment and associated maintenance, or by reducing the number of times that they must 
choose the “programming alternative: 


As a result, many new applications are being developed in a heterogeneous fashion. In 
other words, while some portions of code are written via traditional programming, other 
portions are produced by “generators? or by “report writers” and “query” products. With 
Information Centers, some portions of applications are written and maintained by the end 
user, not just by the data processing department. 


IBM’s new Structured Query Language/Data System (SQL/DS) provides the intermediate 
system installation with a new application development alternative. It is aimed at improv- 
ing the productivity of both the data processing professional and the end user communi- 
ties through a wide range of design and implementation approaches. 
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SQL/DS—An Application 
Development Alternative 
for Intermediate Systems 


SQL/DS is a new IBM program product for the Data Systems Environment; it consists of 

a relational data base facility, a powerful query language, and a standard programming 
interface to COBOL, PL/I, and Assembler. In this sense, it is a tool for the DP 
professional. 


In another sense, there are features that allow applications to be designed so that 
SQL/DS is a very practical tool for the end user. When tailored by the DP professional, 
or Information Center Specialist, SQL/DS is appropriate for the Information Center 
environment. 


Most importantly however, SQL/DS is an integral product of the Data Systems Environ- 
ment. It is designed to work in conjunction with other IBM Data Systems Environment 
products such as CICS/DOS/VS and DL/I DOS/VS. 


Because SQL/DS is designed to work in conjunction with these products, the installation 


can use SQL/DS in many ways, depending on the requirements of the application and 
the capabilities of the end users. These ways are: 


¢ Unplanned end-user query 

¢ Stored query transactions 

* Online CICS/DOS/VS transaction programs 
¢ Batch application programs 


These effectively provide a “building block” approach to design and implementation. This 
approach will be discussed Jater in this publication. 


The relational data base can be shared with an interactive system such as VSE/ICCF. 
COBOL, PL/I, and Assembler language programs can be compiled, edited, and tested 
directly from the terminal with the results received back at the terminal. Standard submis- 
sion to DOS/VSE batch, use of the interactive usability aids, the procedure processor, 
and the online library system of ICCF are completely supported in this environment. 


SQL/DS is flexible in permitting either centralized or decentralized administration of data 
,..and most administrative tasks can be performed via terminals. 


SQL/DS is normally operated in a way that many users and applications can access 
SQL/DS data concurrently. Data access can be controlled by a comprehensive authoriza- 
tion facility and a set of system catalogs. The system also includes facilities for controlling 
the security and integrity of its data, even in the event of abnormal termination of applica- 
tion programs, SQL/DS itself, or the operating system. 


SQL/DS also provides facilities for bulk-loading new data or data from existing systems 
into its relational data base. For example, it may be desirable to apply the advantages of 
SQL/DS to existing portions of DL/I applications. The interactive query language includes 
commands to extract data from the DL/I data base and copy it into SQL/DS. 
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The Relational 
Approach 


An objective of the relational approach is to simplify data base design and processing for 
programmers and end users. This is achieved through the use of a familiar form of 
logical data organization—a table—and a high-level language especially designed to 
take advantage of data in tabular form. 


Traditionally, data in and out of business is in tabular form; that is, in the form of either 
tables or reports, which have a title and columns of data. And, of course, in these tables 
or reports are multiple lines or rows. The relational data structure is a table and allows 
users to perceive their collection of reports as a collection of tables. 


In the figure below, the rows of the INVENTORY table can be thought of as instances of 
records. The columns INVPART, PNAME, and ONHAND can be thought of as fields 
for these records. Note that the word “perceived” is essential; how this data is actually 
stored is not relevant to the relational view. 


INVENTORY Table 


| INVPART | PNAME ONHAND 


GEAR 0 





In addition, the tabular view of data contains no physical access paths that are visible to 
the user. This means that access paths, such as links, rings, chains, indexes, etc., do 
not have to be learned and remembered by the user for purposes of navigating through 
the data base. Therefore, since the user does not need to consider access paths, the 
formulation of requests for data is simplified. 


Relationships between rows in one table and rows in another can be established dynami- 
cally using the facilities of the relational language. For example, suppose we need to 
determine the name of the suppliers of part 124 from the two tables shown below. ' 


SUPPLIERS Table 


| SUPSUPP ADDRESS 


53 ATLANTIS CO. 8 OCEAN AVE., WASHINGTON, D.C. 


5/ EAGLE HARDWARE | 64 TRANQUILITY PLACE, APOLLO, MN 
64 KNIGHT LTD. 256 ARTHUR COURT, CAMELOT, ENGLAND 





QUOTATIONS Table 
QUOSUPP QUOPART 





PRICE TIME ONORD 


1.20 s) 400 
0.55 > 0 
1.35 3 900 


‘The names used herein are fictitious; they are used solely for illustrative purposes and are not for identification 
of any company. 
















set 
Processing 


Tabular 
Output 


First, the supplier numbers (QUOSUPP) for part 124 need to be identified by examining 
the QUOTATIONS table. Next, the supplier numbers obtained from this table are com- 
pared to the supplier numbers (SUPSUPP) In the SUPPLIERS table. When they match, 
the system extracts NAMEs from those rows in the SUPPLIERS table. 


This table-lookup process is accomplished using the operators of the relational language; 
there is no need to use conventional programming techniques to obtain the information 
needed. 


The important point here is that many interrecord or intertable relationships can be 
established by the user spontaneously. With conventional approaches, only those rela- 
tionships that were defined prior to the creation of the data base can be used this simply. 


The relational language provides operators that process sets of records at a time, rather 
than single record-at-a-time processing. A single relational request can be used to selec- 
tively retrieve data from multiple rows of multiple tables for presentation to the terminal 
user. Similarly, a single relational request can be used to selectively update or delete 
multiple rows of a single table. In conventional language approaches, such operations 
would require multiple requests to the data manager. 


The result of a relational query, or request, is also presented to the user in the form of a 
table. By adding some commands to the original query, the user can make the query 
result a permanent table. In this way, new tables that are (later) needed can be defined 
dynamically and easily, can be generated online, and become immediately available 
as part of the entire collection of tables within the system. 
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The tabular view is a primary reason why a relational system is easy to understand. Since 
the data structure is familiar to most users, there is greater potential for improved commu- 
nications with the data processing organization when specifying information requirements. 


The relational query language used in SQL/DS is called Structured Query Language 
(SQL). Its data handling capabilities, being geared to operations on sets of records, 
can mean a significant reduction in the number of statements the user must provide, 
compared to many existing languages. 


There are many application areas—particularly those involving user analysis, reporting, 
and planning— where the very nature of the application is constantly changing. Some 
typical application areas are: 


* Financial 

- Budget analysis 
- Profit and loss 

- Risk assessment 


* Inventory 
- Vendor performance 
- Buyer performance 


* Marketing & sales 
- Tracking & analysis 


* Personnel 
- Compliance 
- Skills and job tracking 


* Project management 
- Checkpoint/milestone progress 
- Development and test status 


* EDP auditing 
- Data verification 
- Installation configuration 


* Government/education/health 
- Crime and traffic analysis 

- Admissions/recruiting/research 
- Medical data analysis 


These applications typify instances where it is of primary importance to establish inter- 
relationships within the data base and to define new tables. 


The fact that the relational approach provides certain advantages over existing systems 
for specific applications does not mean that it replaces them. SQL/DS is designed to work 
in conjunction with several other IBM application development facilities in the Data Sys- 
tems Environment. 


This means that the developer is not limited to a single approach to develop an applica- 
tion and can determine the most appropriate development technique for each phase 
of the application. 
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Productivity Aspects 
of SQL/DS 


In many installations, the key to overall productivity is the ability of DP to offload the 
appropriate portions of the development and maintenance of an application to the 
end user. 


The flexible design approach mentioned above allows an application to be designed with 
the end user’s capabilities in mind. This could enable the DP professional to implement 
an application up to the point where the end user could create and execute his own 
queries, thereby expanding the application on his own and reducing his dependence on 
the data processing department. 


All of these characteristics make SQL/DS a powerful prototyping tool. The terminal facili- 
ties of SQL/DS can be used to create prototype tables loaded with sample or production 
data. Online queries can easily be written to demonstrate application usage. End users 
can see the proposed scheme in operation prior to formal DP development. In this proto- 
type approach, people time and computer time are saved while design flaws are easily 
corrected at an early phase. 


Considering all of the facilities provided by SQL/DS and the fact that it operates in con- 
junction with CICS/DOS/VS and DL/I DOS/VS, it is obvious that elements of a data sys- 
tems environment are there. SQL/DS is especially appropriate for non-integrated 
applications, or for those applications that must be implemented in a relatively short time. 











12 


New 
Applications 


A Variety of Building 
Blocks to Help 

You Build 

an Application 


Application Design 
Approaches 


Let’s take a brief look at how an installation might use SQL/DS for new applications, or for 
extending existing applications. We'll consider new applications first. 





Created Ad Hoc 
by the Queries 
end user 


Developed Predefined Parameter- 
by the DP Queries Driven 
professional Queries 





Batch 
Programs 


Online 
Transaction 
Programs 
(CICS) 





Relational Data Base 





As you can see from the illustration above, there are building blocks for both the DP 
professional and the end user. Depending on the application, one could initially develop 
most of the basic functions of the application using the high level SQL language. 


Once the data base is created, the end user, depending on his capabilities, could begin to 
write queries. Repetitively run queries could be predefined and stored for later use. 
There is even the capability to store queries so that they can be “parameter-driven? just 
like online transactions. 


Of course, some of the more difficult queries will be written by DP, which may also elect 
to code specific online functions using a programming language. This decision to “hard 
code” or use a programming alternative may be posiponed until after the application 

is verified. 
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In many of today’s applications, significant potential remains unrealized because the data 
cannot be made more readily available to the end user. In such situations, data is main- 
tained on a regular schedule through some Set of operational applications, possibly even 
in a data base system. Often, however, the typical programming costs to extend the use 
of that data for planning, reporting, and analysis purposes put a “lock” on the information. 


SQL/DS can help “unlock” this data. By using the extraction and loading facilities of 
SQL/DS, “old data” can be given new life by transferring it to relational form. Both the DP 
professional (or Information Center Specialist) and the using department could develop 
the needed improvements using the interactive query language. 
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Highlights 


Structure 


The interactive query language consists of the Structured Query Language (SQL) and 
additional commands that provide access to tabular data. Using familiar words like 
SELECT, FROM, WHERE, and others, you can 

¢ List all or parts of a table 

¢ Sort or sequence the data 

¢ Combine data in one table with data from another 

¢ Perform calculations based on common arithmetic functions 


e Invoke various built-in functions such as SUM and COUNT 


¢ Format the output by adding a bottom page title, changing the top page title, and adding 
subtotal and total lines, all of which can improve the appearance of the report 


° Enter, update, and delete data 


Several examples of these language capabilities will be shown later in this publication. 
Before that, however, let’s take a closer look at the structure of the language. 


Retrieving data is the most fundamental task of SQL and, for this function, the SELECT 
command is used. The basic form of the SELECT command is: 


SELECT some data (field names) 
FROM some place (table names) 
WHERE certain conditions (if any) are to be met 


In some instances, WHERE may not be necessary. This is shown in the first few sample 
queries. However, many special needs can be expressed in the WHERE part of the query, 
and these will be shown later. 


Around this SELECT...FROM...WHERE structure, the user can place other SQL com- 
mands in order to express the many powerful operations of the language. 


In all uses of SQL, the user does not have to be concerned with how the system should 
get the data. Rather, the user tells the system what he wants. This means that the user 
only needs to know the meaning of the data, not its physical representation, and this 
feature can relieve the user from many of the complexities of data access. 
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Sample Data Base Most of the examples in this book use three tables that we've created called INVENTORY, 
QUOTATIONS, and SUPPLIERS. Let’s look at the data in these tables by using simple 
queries. 


First, we'll list INVENTORY in part number sequence. The commands io do this are: 


SELECT * = 







shorthand for ORDER BY INVPART 


“all fields” 





PRINT 





Name of table tram 
which fields specified 
in SELECT are obtained 


Order fhe output by 
part number 


indicates hard copy as 
well as display 


Hard-copy 


ee — & 1/20/81 SELECT * FROM INVENTORY ORDER BY INVPART PAGE ug 
The first 50 characters 


matically printed when 108 GEAR : = 5 
no page title is speci- 106 GEAR 700 
fied in the query. 124 BOLT 900 
125 BOLT 1000 
134 NUT 900 
135 NUT 1000 
171 GENERATOR 500 
172 GENERATOR 400 
181 WHEEL 1000 
182 WHEEL 1100 
207 GEAR 7500 
209 CAM 5000 
221 BOLT 65000 
2zZ2 BOLT 125000 
231 NUT 70000 
232 NUT 110000 
241 WASHER 600000 
285 WHEEL 35000 


4935 BELT 8500 


Now let's see all of the data in the QUOTATIONS table and order the output by pan within 
supplier number: 





User 

Throughout this pubii- 

cation hyphens are SHE CECT RETON : 

used for continuing aces : a 

itt ateilemmmeen ais ORDER BY QUOSUPP,QUOPART 

multiple lines when PRINT 

entered from the 

lenminal, 

PoNonc aes 1/20/81 SELECT * FROM QUOTATIONS ORDER BY QUOSUPP,QUOPART PAGE 1 

utpu 

ee QUOPART PRICE TIME ONORD 

Since we did not spec- Rete Serer sw ceeseese oneetes  eeceenn----- 

ity the left-to-right >t 124 1.25 2 400 

2 51 125 0.55 5 0 

order of the columns in 51 134 0.40 5 500 

the SELECT request, 51 135 0.39 5 1000 

the columns are pre- Ba oa “e 4 ss pietohds 

eI a a ee ee ra 
52 205 0.15 20 ) 

table was created. 52 206 0.15 20 0 
53 124 1.35 3 500 
53 125 0.58 3 0 
53 134 0.38 3 200 
53 135 0.42 3 1000 
53 222 0.25 15 10000 
53 232 0.10 15 20000 
53 241 0.08 15 6000 
54 134 0.47 4 0 
54 171 21.75 20 200 
54 209 18.00 21 200 
54 221 0.10 30 5000 
54 231 0.04 30 15000 
54 241 0.02 30 10000 
57 172 45.15 25 300 
57 285 21.00 14 0 
57 295 8.50 21 2400 
61 105 9.95 a 400 
61 106 4.35 8 300 
61 221 0.20 21 5000 
61 222 0.20 21 10000 
61 241 0.05 21 4000 
64 106 4.85 10 ) 
64 181 5.65 15 400 
64 182 7.05 10 400 
64 207 29.00 14 2000 
64 209 19.50 7 800 
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Finally, let’s create a listing of the SUPPLIERS table. In this case, we want a specific left- 
to-right appearance of the data in our /ist. This differs from the left-to-right appearance 
in the data base. We specify this alteration in the SELECT statement. 


User 

Tnis 1s the actual left- 
fo-ight appearance 
that we want the data 
fo have. As stored 

in the SUPPLIERS 
fable, however, 
SUPSUPP actually 
appears before NAME, 


Hard-copy 
Output 





NOTE: For ease of reference in using the examples in this book, the data in INVENTORY, 
QUOTATIONS, and SUPPLIERS is shown on the foldout page attached to the back cover. 
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Defining a 
Table 


User 


NOT NULL means each 
row of the fable must 
Have 4 part number 


Haltword binary 


The tabular form of data as stored in SQL/DS is easy to access and understand. There 
are no embedded pointers or special paths to consider, The user just focuses on the data 
and its meaning. These same characteristics allow the data definition and creation proc- 
ess to be simple as well. 


Before a table can be loaded, it must first be defined. The following command was used 
to define the INVENTORY table: 


CREATE TABLE INVENTORY (INVPART SMALLINT NOT NULL, - 
PNAME CHAR(10), - 
ONHAND INTEGER) 


The QUOTATIONS table and the SUPPLIERS table were defined by these two 
commands: 


CREATE TABLE QUOTATIONS (QUOSUPP SMALLINT NOT NULL, - 
QUOPART SMALLINT NOT NULL, - 
PRICE DECIMAL(5,2), - 


TIME | INTEGER)’ - 


Fullword binary 


CREATE TABLE SUPPLIERS (SUPSUPP SMALLINT NOT NULL, - 
NAME CHAR(15), - 
ADDRESS VARCHAR(35)) 


We also defined synonyms for the INVENTORY and QUOTATIONS tabdles to save key- 
strokes when entering their names. These are the commands we used: 


CREATE SYNONYM INV FOR USER1. INVENTORY 
CREATE SYNONYM QUO FOR USERI. QUOTATIONS 


You will see how these tables can be loaded later in this publication. 


20 The Interactive 
Query Facility of 





SQL/DS 
Simple List Assume we want a list of only those parts for which the balance-on-hand is between 0 
and 1000 units; we want the list in part number sequence. 
User 
Display 


Output 





Queries Using More What if we wanted to see the supplier numbers for the parts identified in the last example 
Than One Table and the quantities ordered from these suppliers. We also want to sequence the output 
by part number within par name. 


Refer to the foldout page of this publication. Notice that the quantity-ordered column 
(ONORD) and the supplier number column (QUOSUPP) are in the QUOTATIONS table. 
To answer this request, we will require information from the INVENTORY table and the 
QUOTATIONS table. (This type of operation is often called a join of tables). 





User SELECT PNAME, INVPART, ONHAND, QUOSUPP,ONORD - 
FROM INV,QUO - 
Names of the tables for WHERE ONHAND BETWEEN O AND 1000 - 


all fields used in «AND QUOPART=INVPART - 
ORDER BY FPNAME, INVPART 
SELECT fine | RUE! 


indicates matching 
fields between tables 


Display PNAME INVPART ONHAND QUOSUPP ONORD 
Output BOLT 124 900 51 400 
BOLT 124 300 53 500 
BOLT 125 1000 53 0 
BOLT 125 1000 5] 0 
GEAR 105 0 52 200 
GEAR 105 0 61 400 
GEAR 106 700 61 300 
GEAR 106 700 64 © 
GENERATOR 171 500 54 200 
GENERATOR 172 400 57 300 
NUT 134 900 51 500 
NUT 134 300 54 0 
NUT 134 500 53 200 
NUT 135 1000 53 1000 
NUT 135 1000 51 1000 
WHEEL 181 1000 64 400 


Even from this simple example, some of the power of SQL should become obvious. Con- 
sider, from a programming point of view, what would be required to do the same thing: 


A record from one file has to be reac, the selection criteria evaluated, and the data 
fields extracted. One of these fields will then be used to find the corresponding rec- 
ords from the other file. Then the other file has to be searched, using this matching 
field. When a record is selectea, the required data has to be extracted and proc- 
essed. In most cases, another record has to be read to see if there are any other 
matching recorcs to process. 


These programming considerations tend to get even more complicated as the number of 
matching files or tables increases. 


This is not the case with SQL because it works on sets of records at a time, and because 
the user does not have to tell it how to go about getting the data. in fact, there are search 
optimizers in the relational access mechanism that attempt to minimize the amount of 
data search processing for the user. 
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Formatting The appearance of the output from the previous query can be improved by making the 
a Report column headings more readable and adding a title. We can also create subtotal lines 


of the orders for each part. For example, if we had just executed the query in the previous 
example, these commands would generate the subsequent formatted report: 


User 

3 FORMAT COLUMN INVPART NAME 'PART' 
Changes INVPARAT to 

PART FORMAT COLUMN PNAME NAME ‘DESCRIPTION’ 


FORMAT COLUMN QUOSUPP NAME ‘SUPPLIER’ 
FORMAT COLUMN ONORD NAME ‘ON ORDER' 
FORMAT COLUMN ONHAND NAME ‘ON HAND' 


— so  .(—nr a FORMAT GROUP DESCRIPTION 
Causes group indica- “Sates ries 
tion on DESCRIPTION FORMAT GROUP PART 
FORMAT SUBTOTAL “ON ORDER” 
Subtotals orders 

. FORMAT TITLE ‘INVENTORY REPORT’ 
Titles report on top of 


PRINT 
page 
Hard-copy 01/20/81 INVENTORY REPORT 
Output 
Pp DESCRIPTION PART ON HAND SUPPLIER ON ORDER 
BOLT 124 - 300 51 400 
900 53 500 
cKKEHK 500 


RRR Ke 





Subtotal lines 


400 

ae 00 

106 700 61 300 

700 64 0 

sect” <i = 7 see Re: 
GENERATOR 17 i 500 54 200 
we ago an 

172 400 a | 300 

tage apr OSs 


REE KEKE KEK 


NUT 134 900 





Built-In Functions The built-in functions of SQL are another indication of the power of the language and can 
Save a significant amount of programming. For example, we can also find the total 
orders for each of the part numbers in the preceding report by using the built-in function 
SUM. This time, let's sequence the output by balance-on-hand in descending order. 


User 
SELECT QUOPART, PNAME, ONHAND,SUM(ONORD) - 
FROM INV,QUO - 
WHERE ONHAND BETWEEN O AND 1000 - 
AND QUOPART = INVPART - 
—  PGROUP BY OUOPART, FNAME, ONHAND - 
fhe sum is calculated ——tORDER BY ONHAND DESC 
for each unique cambi- 
nation of these fields 


Descending order 


Display QUOPART PNAME ONHAND SUM(ONORD) 
Output 181 WHEEL 1000 400 
135 NUT 1000 2000 
125 BOLT 1000 0 
134 NUT 300 700 
124 BOLT 800 $00 
106 GEAR 700 300 
171 GENERATOR 500 200 
172 GENERATOR 400 300 
105 GEAR O 600 


In this simple use of the SUM function, consider what a programmer would probably have 
io do in order to accomplish the same thing. 


First, a list of parts ordered has to be obtained and sequenced by part number within part 
name. Then, a subtotal of the orders has to be computed by part number and Saved. 


Next, a listing for output has to be developed for those parts matching the search criteria 
(performing all ihe things we had to do in “Queries Using More Than One Table") and, 
for each part, the on-order subtotals previously saved must be retrieved. Finally, the 
listing has to be sorted by quantity-on-hana, in descending sequence. 


Almost every one of these operations requires a record to be read, or some data stored 
and a location posted. And, for each |/O operation, return codes and ancillary logic are 
usually necessary. 


24 The Interactive 
Query Facility of 
SQL/DS 





Let's consider another example of the power of ouilt-in functions. For every part in our 
inventory, we want to list the minimum, maximum, and average prices charged by the 
Various Suppliers and we also want to show a count of the number of suppliers that we 
have for eacn part. We will use the MIN, MAX, AVG, and COUNT built-in functions to do this. 


User 


The COUNT(*) allows 
us fo count the number 
of occurrences within 


SELECT QUOPART, PNAME,MIN( PRICE) ,MAX(PRICE),AVG( PRICE) ,COUNT(*) = 





each group defined FROM INV,QUO - 
by the GROUP BY WHERE QUOPART=INVPART - 
p> ined ——* GROUP BY QUOPART, PNAME - 
: ORDER BY QUOPART 
indicates matching | AR he fahcal 
é aapabeagshth feans the fifth column 
field between INV and FORMAT COLUMN 5 PRECISION 3 : 


QUO i 


Indicates the level al Reduces the precision 
which to calculate to 3 decimal places 


the built-in functions 





FORMAT COLUMN 6 NAME ‘NO OF SUPPLIERS' 








Replace heading of 


column Six 

Display QUOPART PNAME MIN(PRICE) MAX(PRICE) AVG(PRICE) NO OF SUPPLIERS 

Output 105 GEAR 7,50 9.95 8.725 2 
106 GEAR 4.35 4.85 4.600 2 
124 BOLT Lo25 1.35 1.300 Zz 
125 BOLT 0.55 0.58 0.565 2 
134 NUT 0.38 0.47 0.417 3 
135 NUT 0.39 0.42 0.405 2 
171 GENERATOR hs = pee ome be 21.750 1 
172 GENERATOR 45.15 45.15 45.150 1 
181 WHEEL 5.65 5.65 5.650 i 
182 WHEEL 7.05 7.05 7.050 i 
207 GEAR 23.00 29.00 29.000 1 
209 CAM 18.00 19.50 18.750 Zz 
Z2Zl BOLT 0.10 0.30 O..200 3 
222 BOLT 0.20 0.25 0.225 2 
231 NUT 0.04 0.10 0.070 2 
232 NUT 0.10 0.10 0.100 1 
241 WASHER 0.02 0.08 0.050 3 
285 WHEEL 21.00 21.00 21.000 B | 
295 BELT 8.50 8.50 8.500 ] 


Tailoring SQL/DS 
for the End User 


Tailoring— 
Creating 
a View 


User 


SQL/DS was designed for a broad range of users with varying backgrounds and different 
capabilities. While many people will be able to learn much of the query language, the 

DP professional or Information Center Specialist can further simplify its use by creating 
views, Stored queries, and parameter-criven queries. 


For some users, a single table may be considerably easier lo work with than muiliple 
ladles. In addition to tables, SQL supports views. A view is a logical (or “virtual”) table 
that is derived from one or more tabies or other views. In general, views look like, and 
can be operated on, jusi as if they were real tables. They can simplify data access 
requests and can reduce keystrokes and errors, 


To create a sing/e-table view of the data from our three tables for ihe users in the Nuts 
and Bolts Department (department 17) so that they may retrieve their data as if it were in 
a single table, we could enter the following: 


CREATE VIEW D17INVENTORY (SUPPNAME, ADDRESS,D17PART,PARTNAME,LEADTIME, - 
ONHAND, ONORDER, PRICE, TOTALPRICE) AS - 
SELECT NAME, ADDRESS, QOUOPART, - . 
PNAME, TIME, ONHAND, ONORD, PRICE, PRICE*ONORD - 
FROM INV,QUO, SUPPLIERS = 
WHERE INVPART = QUOPART - 
AND SUPSUPP = QUOSUPP a 
AND PNAME IN (‘NUT', ‘BOLT') 


—— 


D17 INVENTORY 


SUPPNAME | ADDRESS|D17PRAT| PARTNAME A070 OwAND ononoer 
| 








Users in Department D17 would think of their data as if it were all in a single table, as 
shown above. Only the DP department would need to know that the data is actually stored 
In several tables. 


The end user is thus insulated from the actual physical data storage. Moreover, it is possi- 
ble for the underlying data storage to change (for example. the fields in a table could be 
rearranged or new fields could be added) and the user would neither know or care. 


User 


The Interactive 

Query Facility of 

SQL/DS 

Now that their data appears as a single table, the users queries are simpler to write. 
Consider how easily the following ad hoc requests might be answered by the inventory 
department using SQL/DS. 


How much do we owe TITANIC PARTS? 


$e citer Sui TOTAL erie = 


TOTALPRICE is a pre- 
detined calculation 
stored in the view 


Disolay 
Output 


User 


Display 
Output 


User 


DISTINCT gives us a 
count of [ne part num- 
bers that are distinct, 
not just a count of part 
numbers within the 
DIZPART column 
(which would inciude 
duplicates) 


Display 
Output 


User 





The % signs Cause a 
search for the charac- 
fer string anywhere 

in the ADDRESS field. 


Display 
Outout 


FROM DI7INVENTORY - 
WHERE SUPPNAME = ‘TITANIC PARTS' 


»UM(TOTALPRICE ) 
1100.00 


How much do we owe our Suppliers for BOLTS? 


SELECT SUM(TOTALPRICE) - 
FROM DI17INVENTORY - 
WHERE PARTNAME = 'BOLT'’ 


SUM(TOTALPRICE) 
10175.00 


How many different parts do we stock? 


SELECT COUNT(DISTINCT D17PART) - 
FROM D17 INVENTORY 


COUNT (DISTINCT D1?7PART) 


i ee ee ee ee 


B 


Do we have a supplier located in TACOMA? 


SELECT DISTINCT SUPPNAME, ADDRESS 
FROM D17INVENTORY - 
WHERE ADDRESS LIKE 'Y%TACOMAY' 





SUPPNAME ADDRESS 
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Tailoring— You can save a query for later use without having to re-enter it when it has to be used. 

Stored 

Queries Let’s say, for example, that the queries created on the DI7INVENTORY view were going 
to be frequently used by our inventory clerks. The quéry for the SUM of TOTALPRICE 

User for BOLTs could be made a permanent part of a clerk's query library by entering: 





HOLD causes the 
query to be held for 
further processing HOLD SELECT SUM(TOTALPRICE) = 


before execution WHERE PARTNAME =’ BOLT’ 


STORE causes the Ls STORE BOLTS 
currently held query fo 


be stored for execution 
by name 





Svar < ead ie axe. Whenever our inventory clerks have to run that report, they would enter: 


cule a query tnat has 
been stored 
——s START BOLTS 


Tatloring— Users can also store a query in such a way that allows it to be tailored to meet specific 
Parameter-Driven requests at execution time. 
Queries 


lf a user wanted to be able to find the name and address of suppliers from any given city, 
he could store a parameter-driven query that produced the result for a specific city by 
entering: 


HOLD SELECT DISTINCT SUPPNAME,ADDRESS - 


User FROM DI7INVENTORY - 
_———_________—__» WHERE ADDRESS LIKE 'Y &] ¥' 
&1 is the parameter for STORE SUPPCITY 


which a city name 
will be substituted by 
the user when he 
“starts Nis query. 


To execute this query for CAMELOT, the user would enter: 


User START SUPPCITY (CAMELOT) 

Display SUPPNAME ADDRESS 

Output —veramalahos Be robe. sagen aio tay ooricen erate Ne 
KNIGHT LTD. 256 ARTHUR COURT, CAMELOT ENGLAND 
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Making 
Changes to 
Stored Data 


Modifying 
Data 


User 


Hard-copy 
Outout 


The Interactive 
Query Facility of 
SQL/DS 


SQL/DS allows users to modify, delete, and insert data into shared or private tables. 
These operations can be performed interactively from the terminal and can be especially 
useful to persons who would like to maintain their own records. The following examples 
will give you an idea of the scope of the system’s capabilities in this area. 


Suppose supplier 51 increases his prices by 11%. We have to update QUOTATIONS to 


reflect this change. 


UPDATE QUO - 
SET PRICE = PRICE * 1.11 - 
WHERE QUOSUPP = 51 


A subsequent query on this table would confirm the update. 


SELECT * FROM QUO ORDER BY QUOSUPP 
PRINT 


1/20/81 SELECT * FROM QUO ORDER BY QUOSUPP PAGE 1 


QUOSUPP QUOPART PRICE TIME ONORD 
51 134 0.44 5 200 
51 124 38 5 400 
== 221 0.33 10 10000 
51 231 On dd 10 5000 
=z 125 0.61 5 0 
51 135 0.43 5 1000 
BZ 205 Re Lo 20 0 
52 206 0.15 20 0 
52 105 7.50 10 200 
53 241 0,08 15 6000 
53 232 0.10 1s 20000 
53 222 G.Z25 15 10000 
53 135 0.42 3 1000 
33 134 0.38 3 200 
are 124 1.35 3 500 
53 125 0.58 3 0 
54 209 18.00 21 200 
24 134 0.47 4 0 
54 171 21.75 20 200 
54 241 0.02 30 10000 
54 231 0.04 30 15000 
54 Z21 O.10 30 aes 
57 295 8.50 rp’ 

27 285 21.00 es 
mk 172 45.75 


Users of views containing PRICE (such as Di7INVENTORY) would automatically have 
this increase reflected in their data. 
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Adding Columns 
to a Table 


User 


User 


suppose that we require new columns in the QUOTATIONS table for DISCOUNTRATE 
and DISCOUNTQTY. These columns may be added to the table using the following SQL 
commands: 


ALTER TABLE QUOTATIONS - 
ADD DISCOUNTRATE DECIMAL (2,2) 


ALTER TABLE QUOTATIONS = 
ADD DISCOUNTQTY INTEGER 


With SQUDS, these data definitions are dynamically executed. All the existing rows of 
ihe QUOTATIONS tabie are effectively expanded and stored with an initial “null” value 
and the user need not be concerned with “reorganizing” the data. 


Another feature of SQL/DS is that most queries and views that referred to the QUOTA- 
TIONS table before these columns were addec do not have to be modified. For example, 
ihe D17INVENTORY view is not affected by this modification. 


Actual data for these new columns would be entered using a series of UPDATE com- 
mands. For example, assume that TITANIC PARTS (supplier number 54) has a discount 
rate of 10 percent on parts over 10 dollars and a discount rate of 5 percent on parts 10 
dollars or less. Furthermore, assume their discount quantity 1s 20 for the former and 100 
for the latter sets of parts. This information can be added to the QUOTATIONS table 
using the following UPDATE commands: 


UPDATE QUOTATIONS - 
SET DISCOUNTRATE=.10,DISCOUNTOTY=20 - 
WHERE QUOSUPP=54 - 
AND PRICE > 10 


UPDATE QUOTATIONS = 
SET DISCOUNTRATE=.05,DISCOUNTOTY=100 - 
WHERE QUOSUPP= 54 - 
AND PRICE <= 10 
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User 


Display 
Output 


Each user can set hs 
own “null” character for 
reporting purposes 


Entering Data 
from a 
Terminal 


User 


The Interactive 
Query Faciltty of 
SQL/DS 


To verify that updates were made, we can query the (newly expanded) QUOTATIONS 


table. Notice that the quotations for which no discount rate or discount quantity has been 
entered have “null” (7) entries in the corresponding columns. 


SELECT QUOSUPP, QUOPART, PRICE, DISCOUNTRATE, DISCOUNTQTY - 
FROM QUOTATIONS = 

WHERE QUOSUPP > 53 = 

ORDER BY QUOSUPP, QUOPART 


QUOSUPP QUOPART PRICE DISCOUNTRATE DISCOUNTOTY 
°4 134 0.47 O.C5 100 
54 171 2i4<i5 0.10 20 
54 209 18.00 0.10 vA®) 
54 221 0.10 0.05 109 
54 yA 0.04 0,05 150 
54 241 0.02 0.05 100 

Lia aa - ? 
1.¢ ? ? 
8. ? ? 
Fi ? rs 
4s ? ? 
or ? > 
0. ? ? 
0. ? ? 
4. ? | 
oy ? ? 
Ti # ? 
— ? ? 
a. ? ? 





Entire rows of data, or portions of rows of data, can be entered by the user directly from 
the terminal. Suppose the purchasing department was negotiating contracts with new 
suppliers. If supplier numbers were assigned, we could add new rows to the SUPPLIERS 
table as follows: 


© INSERT INTO SUPPLIERS (NAME, ADDRESS, SUPSUPP) - 


lo insert a single row 
into a fable 


fo insert multiple rows 
into 2 fable 


VALUES (‘OLYMPUS CORP',‘12 KROE ST., COS COB CT',66) 


Or 


INPUT SUPPLIERS (NAME,ADDRESS,SUPSUPP) 
‘VILLAGE PARTS' ,'347 HILLSBORO AVE., PHILA PA‘ ,67 
‘PLASTICS INC.','16 HIGHMEADOW RD., ST.LOUIS MO' ,72 
‘SUPERIOR METALS','160 SANDPIPER AVE., MOUNTAIN VIEW CA',70 
END 
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The System Catalogs 
of SQL/DS 


Managing 

a Typical DP 
Department 
Problem 


Data and 
System 
Administration 


In every business, someone is responsible for such assets as cash, inventory, and pro- 
duction, and for the standards and procedures that make a business run. Within a 
data processing department, there is a similar need to control, audit, and protect its 
resources. 


This requires documentation about data, programs, queries, and users. It also means that 
the data definitions and relationships between these items must be documented so that 
they can be made available whenever changes occur. Frequently asked questions are: 


* Who accesses the data and which programs use it? 
¢Which programmers are responsible for which applications? 
* What will be affected by changing a particular data field? 


All too often, the initial effort for creating and maintaining this information is greater than 
a department can afford. And, as a result, this important information is scattered through- 
out the DP department: in program listings, in desk drawers, or in people’s memories. 


Data and system administration is aided by use of the SQL/DS system catalogs. These 
catalogs are a special set of tables, which are totally integrated into the system, and 
which contain descriptive information on data, programs, users, and other “objects” in the 
SQL/DS system. 


These tables look like and can be queried like any other tables in SQL/DS, except that 
their contents are dynamic and maintained through the use of the SQL Data Definition 
commands, rather than through UPDATE, INSERT, and DELETE commands. Some of 
the items described by the SQL/DS catalogs, and the specific catalog tables that 
describe them are shown below: 


Item Catalog Name Comments 

Tables SYSCATALOG Includes views 

Columns SYSCOLUMNS Includes view columns 
Programs SYSACCESS Information on programs 
Programs SYSUSERAUTH More information on programs 
Users SYSUSERAUTH User authorities 

Synonyms SYSSYNONYMS User synonyms 

Table usage SYSUSAGE Tables used by programs 
Queries STMTS Stored queries 


Let's look at how these catalogs can be used to help manage a typical DP department 
problem. 


A senior programmer (GEORGE) is transferred and we wish to find out which programs/ 
queries he wrote and what tables these programs/queries used. We also want to know 
what tables he created. 





33 


The following queries will give us this information: 
» Find Programs Written by GEORGE 


To find the programs written by senior programmer GEORGE, we would query the SYS- 
ACCESS catalog: 


User SELECT TNAME, TIMESTAMP - 

ws FROM SYSTEM. SYSACCESS - 

Since all the catalogs WHERE CREATOR = ‘GEORGE’ - 

are “owned” by the BN TARTS = 

system, references (to FORMAT COLUMN TNAME NAME PROGRAM 

calalog names must be 

preceded by FORMAT TTITLE ‘GEORGES PROGRAMS 

Hard-copy 1/20/81 GEORGES PROGRAMS PAGE 1 

Output PROGRAM TIMESTAMP 
ORDERPLAN 06/16 /80.16:55:17 
ORDERANALYSIS 06/13/80.18:54:32 
PARTSBUDGET 06/16/80.17:15:23 


« Find Tables Used by GEORGE’s Programs 
Tables used by GEORGE’s programs can be found by querying SYSUSAGE: 





User 

Can be a real table or a SELECT DNAME, BCREATOR,BNAME,BTYPE - 

view FROM SYSTEM.SYSUSAGE - 

—.» WHERE BTYPE IN ('R','V') - 

—_$____W—_—_+____ AND DTYPE = 'X' - 

Using objects are ——*AND DCREATOR = 'GEORGE' = 

programs | ORDER BY DNAME,BCREATOR 

ie ae) FORMAT COLUMN DNAME NAME PROGRAM 

GEORGE's programs FORMAT COLUMN BCREATOR NAME 'TABLE OWNER' 
FORMAT COLUMN BNAME NAME ‘TABLE NAME' 
FORMAT COLUMN BTYPE NAME 'TABLE TYPE' 
FORMAT TTITLE 'TABLES USED. BY GEORGES PROGRAMS' 
PRINT 

Hard-copy 1/20/80 TABLES USED BY GEORGES PROGRAMS PAGE i 

Output PROG TABLE OWNER ‘TABLE NAME TABLE TYPE 
ORDERANALYSIS JONESDA SUPPLIERS R 
ORDERANALYSIS GEORGE D17 INVENTORY Vv 
ORDERPLAN JONESDA INVENTORY R 
ORDERPLAN JONESDA QUOTATIONS R 
PARTSBUDGET JONESDA QUOTATIONS R 
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«Find Tables Created by GEORGE 
To find the tables created by GEORGE, we would query SYSCATALOG: 


User 
HH SELECT TNAME, TABTYPE - 
lable name and type FROM SYSTEM.SYSCATALOG - 
WHERE CREATOR = 'GEORGE' - 
——————* ORDER BY TABTYPE, TNAME 





lo separate views and 
real tables FORMAT COLUMN TNAME NAME 'TABLE NAME' 


FORMAT COLUMN TABTYPE NAME 'TYPE' 
FORMAT TTITLE 'GEORGES TABLES' 


PRINT 


Hard-copy 1/20/81 GEORGES TABLES PAGE 1 
Output TABLE NAME TYPE 


CUSTOMERS 
DEPT 
EMPLOYEES 
COMPOSITE 
DEPT PAY 

D17 INVENTORY 
INV 
ORGANIZATION 
PAYCHECKS 
QUO 


qa<acctcccAwD 


Imagine how much work it would take to accumulate this information manually? 
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Securing 
the Data Base 


User 


Another aspect of data administration and control is data security. Although not all data is 
considered to be “sensilive’, Most end-user applications require Some level of data 
authorization to control the reading and/or writing of data across the data base. The 
ability to share access on tables and views within SOL’DS is provided by the GRANT and 
REVOKE commands. These commands can be used only by those who have been 
authorized to use them or by the owners of the tables and views. 


Let's look at Some examples 
Assume that the department manager has decided to allow all users to have only 


retrieval (read) access to the SUPPLIERS table. He would grant their access privilege by 
issuing the following command: 





AS another example, the adminisirator could further authorize USER1 and USER2 to 
update the ADDRESS column in SUPPLIERS: 





JONES ts in the Purchasing Department and negotiates contracts with suppliers num- 
bered 51 ano 53. Lets allow JONES to have update privileges only on these suppliers for 
the PRICE and TIME columns in the QUOTATIONS table. 


First. we define a view on QUO that subsels the data for suppliers 51 and 53 only. 
(JONES already has SELECT access to QUO.) 





Then we grant update access on this view: 





The authorization capability of SQL/DS is quite thorough and can be used to establish 
similar authorizations for other operations such as ALTER, DELETE. and (INSERT. 














36 Loading | Data from 
Existing Files 
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Quite often the information used in analysis and planning applications is derived directly 
from data stored in existing production files. Generally, the user performing the analysis 
requires the data from different points of view and arranged rather differently than it may 
have been structured for the production applications. 


By loading their data into relational tables, these users can obtain the freedom necessary 
to do various queries across these tables in ways which perhaps could not have been 
easily anticipated and predefined. 


Finally, the interactive query language gives users the opportunity to directly access their 
data with less dependence on the data processing professional to write a program for 
each of their requests. 


Although the user could directly enter his data from the terminal, to meet bulk loading 
requirements SQL/DS provides various facilities for loading large volumes of data 
into relational tables from existing files. 





Loading Data 
from Sequential 
Files 







Typically, many information needs can be satisfied simply by putting the data online and 
allowing users to directly access it. 


SQL/DS provides a batch utility program, called Data Base Services (DBS), that provides 
several supportive functions for maintaining the system. The DATALOAD command of 
the DBS Utility allows you to load rows into a previously defined SQL/DS table from data 
contained in a user-created sequential file (SAM). 


We mentioned earlier that SQL/DS can be used in conjunction with an interactive system 
such as IBM's VSE/ICCF-. In this way, even batch programs can be invoked by users 
from their terminals. Invocation of the DBS utility program is a good example of this 
“batch” mode of execution. 


Relational Data Base 





| | 


Extract Load | 
DL/| 
Data Base 
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Load the 
“Equipment” File 
into SQL/DS 


This statement obtains 
the DBS utility 


This statement says the 
DBS command cards 
follow 


This card telis DBS 
who the user is 


—K—X—— 


Loading Data from 
Existing Files 


Many installations maintain a capital equipment file to keep track of depreciated asseis, 
delivery schedules, and cosis. If this dala were loaded into SQL/DS, then the system's 
easy-to-use query facilities would allow the DP department to make timely use of this 
information and keep abreast of changes readily. 


Let’s assume that the “Equipment’ file is Sequential (SAM) and stored on DASD. The 
ICCF user can load this data into SQL/DS using the {CCF library suppon and the SQL/ 
DS DBS uiilily in the following way. 


First, using the ICCF editor, he could duild a OBS job in an ICCF library member (call it 
EQIPLOAD). The resulting job stream would look like this: 





This job could then be run by executing the library member: 


The DBS utility messages could be transmitted to the terminal so the user would see ' | 
when his table was loaded. Al that point, he could sign on to SQL’DS ana immediately 
begin to query ihe new table. 





Extracting and 
Loading Data from 
DL/| Data Bases 


Administrator 


User (USER1) 


The SA owns INVDB 


and /s sharing it with 
(hese users 


System 








Tne online DL’! EXTRACT facility allows users to issue requests for DL/I data from their 
terminals, yet provides the system administrator with a high degree of central control. 
This arrangement allows the Data Base Administrator to determine the proper time to 
actually execute the Gata transfer. The most appropriate time, for example, may be at off- 
peak hours. 


All phases of the extraction process are invoked by the interactive query language and a 
typical application is described in the following examples. 


Let's assume that the INVENTORY table data comes from our DL/I data base. Before the 
SQL/DS EXTRACT facility can communicate with DL/I, the system administrator must 
first describe to SQL/DS the DL/I data needed by INVENTORY. 


This is done online, using DEFINE commands of the interactive query language (not 
shown). These definitions are stored in the SQL/DS catalogs, and refers to special kinds 
of tables called externa! data tables (EDTs). 


In our example, let’s say that the system administrator called this external data table 
INVDB PARTS, and that USER1 and others want to access it In order to load their tables. 


Using the following commands, the administrator gives three users the authority to issue 
EXTRACT commands against INVDB PARTS: 


GRANT EXTRACT ON INVDB_PARTS TO USERI1 
GRANT EXTRACT ON INVDB_PARTS TO USER2 
GRANT EXTRACT ON INVDB_PARTS TO USER3 


Once a user has been granted “extract” privileges, he can request that the DL/I data be 
copied to the SQL/DS tables for which he has been authorized for insert operations. 


EXTRACT INTO INV(INVPART, PNAME,ONHAND) - 
SELECT ( PARTS_NUMBER, PARTS_DESCR, PARTS_BALANCE) - 


————* FROM SA. INVDB_PARTS 


The system will put the request on the EXTRACT queue, and assign an EXTRACT ID 
(extract identification number) for the request. An information message is issued to the 
user (USER1) giving him the EXTRACT ID (for example, 56). 


EXTRACT REQUEST NOW IS WAITING TO BE SUBMITTED. 
EXTRACT ID IS 56. 





Administrator 


The Administrator is = 
asking for all outstand- 
ing requests 


System 


Administrator 

The Administrator is 
submitting all requests 
agains! the INVDB 
data base 

User (USER1) 


The user Is asking for 
the status of all his 
requests 


System 


User (USER1) 


Loading Data from 
Existing Files 





At the appropriate time, the administrator determines If there were any outstanding 
extract requests and submits the queue of INVDB requests for execution as follows: 








Users can determine the status of their extracts by entering: 





The status of the user's requests will be displayed. If the extract run has been completed. 
the system responds as follows: 





With the run completed, USER1 would then want to delete the entry in the EXTRACT 
queue. This would be done by issuing the DELETEQ request for EXTRACTID 56: 





The user-to-system dialogue facility autornates many of the manual activities typical of 
data extraction procedures. It allows users and the system administrator to carry on their 
regular activities without needing to be in constant touch with one another. 
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Online 
Transactions 

Via COBOL, PL/), 
or Assembler 


Developing Transaction 
Programs with CICS/DOS/VS 


SQL/DS is not just for end-user access. One can also use its facilities in a normal appli- 
calion program. 


In order fo provide special functions, or to access other data (e.g. DL/!} along with SQL’ 
DS data, or to improve the efficiency of highly repetitive operations, it may be more 
aopropriate to develop online transaction programs instead of writing interactive SQL 
queries. 


AS an application programmer, you can develop online transactions in one of these host 


programming languages by using SQL statements inline in your program. 


Let's see how we might do this in a COBOL program that will be executed as a CICS 
transaction. 


Suppose the purchasing department wants to determine the suppliers of “overpriced” 
parts so that it can renegotiate orders. 


The transaction program will have lo develop a list of suppliers whose orice for a part 
exceeds the average price for that part. 


For each of these suppliers, the program also has to retrieve the part numbers. the 
quantities on hand for these parts, and the quantities our customers are ordering from 
us for the parts. 


All but the customer order information can be retrieved from the SQL/DS data base. 
However, our customer order entry system, which is on DL/I, uniquely contains the cus- 
tomer orders. Therefore, the program has to access both the SQL/DS and tne DL/ 
data bases. 


We want the program to develop screens similar to the one shown below, giving the 
purchasing agent the information needed. 


SUPPLIER STATUS 


FE QUANTITY 

i ON ORDER TOTAL 

A INV FROM SUPPLIER AVERAGE CUSTOMER 

G SUPPLIER # PART # STATUS SUPPLIER PRICE PRICE ORDER 

* 51 221 65,000 10,000 30 .20 12,450 
51 231 70,000 5,000 10 07 55,000 

* 53 241 60, 000 6,000 08 05 26,000 

* 64 209 5,000 800 19.50 18.75 975 


CICS Transaction Program 


SQL/DS 


COBOL User 
Terminal! 


————— 





Portions of a COBOL program to retrieve this information are shown below. 


WORKING STORAGE SECTION. 
: EXEC SOL INCLUDE SQLCA END-EXEC 
This causes the SQL ! 


return code structure to 
be automatically gener- = _=Ssss—, e¥Ee SOL BEGIN DECLARE SECTION END-EXEC. 


ated in the program, | O01 SUPP PIC 89(9) COMP. 
Ol PART PIC $9(9) COMP. 


This section identifies ee tet PIC 4a hs }V9(2) COMP-3. 
ONORD PIC S9(9) COMP. 

ne program Vvanabies AVPRC PIC $9(3)V9(2) COMP-? 

[0 be used IF} SOL ww PTC SSO(S)\ rennees 

Statements. 


PROCEDURE DIVISION: 


_______________SsEyne S61 WHENEVER SOLEHROR GoTo 
This statement identi- ERROR-RECOVERY END-EXEC. 
fies where to find error- ' 

handling logic for 


SQL errors. ——*EKEC SOL DECLARE Cl CURSOR FOR 
SELECT QUOSUPP, QUOPART, PRICE, ONORD, AVPRC, INVOH 
————————— FROM 0UO, TEMP 
This statement defines WHERE QUOPART = TEMPPART 
a cursor for stepping : AND PRICE > AVPRC 
through the query END-EXEC. 
results one row ata 


time. : 
GETNEXT. 
CC —————Jxvwwoooo Se ee ero oe 
The FETCH statement INTO :SUPP,:PART, : PRICE, :ONORD, :AVPRC, : INVOH 


retrieves one row of the END-EXEC. 
query result and puts 

the field values in 

the program variables CALCORDER. 
identified by the INTO 

clause. 


<i BUT LDMAP. 
This routine builds the 
output screen (code 
not shown), | 
EXEC DL/I GET UNIQUE USING PCB(1) 

SEGMENT (PARTSEG) WHERE (KEY = PART-NUMBER) INTO 
For each new part, a (PART-SEG-IN) END-EXEC. 
DL! call is executed to 
retrieve tne customer 
order directly from 
the DL data Dase. 







EXEC CICS RETURN END-EXEC. 


The program could 
also make an @valua- 
tion of the inventory 
Status and the cus- 
fomer craers, based on 
other indicative infor- 
mation, and flag those 
supply orders that 
aopear cancelable. 
The purchasing agent, 
of course, would make 
the decision. (This 
code is not shown.) 
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Using Multiple 
Queries Together 
Creating a Temporary 
Fable Querying 

Three Tables 


User 


Result 


The SQL language exploits the power of relational operations and allows the user to 
clearly state the solution to solve the problem 


The examoles that fol'iow arc more complex than the earlier examples of the SQL lan- 
guage shown. These exampies are presented so that you can appreciate the power and 
scope of the SQL relational operations, although, at this point. you may not completely 
understand the language. 


At tne very least. these sample queries should make it clear that an SQL user. In rela- 
lively few statements. can define operations that could take several pages of statements 
using traditional programming languages and pernaps several days to debug. 


Assume that our Inventory aeparniment is instituting a new ordering policy: “NEW 
ORDERS MUST EXCEED TWICE TRE REMAINING BALANCE? Let's see those parts, 
with supplier and price, when this rule is not in effect 


As you can see from the output in the “min/max" example of the “Built-in Functions” 
section, more than one supplier usually supplies each part, and there may be multiple 
orders for a part. However, in our data base, there is no single fieid that contains the total 
orders for each part (This often happens in a data base. One does not always store 
computed fields for every requirement.) 


One simple approach to solving our problem when we need {o know the total orders is 
shown below. 


First Step: First we duild a temporary table creating the field we need (TOTORDER), and 
then we query against thal field. 


CREATE TABLE TEMP (TEMPPART INTEGER. TOTORDER INTEGER) 


INSERT INTO TEMP VALUES SELECT QUOPART,SUM(ONORD) - 
FROM QUO - 
GROUP BY QUOPART 


TEMP Table 
TEMPPART | TOTORDER | 


———— . —! 


106 | 300 
124 900 
4125 0 








q95 | HOD 
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Uses of SQL 


eS = mee 


second Step: Now we can access the new table, along with the QUOTATIONS and 
INVENTORY tables, to get our answer. 





SELECT QUOPART, PNAME, QUOSUPP,PRICE,ONHAND,ONORD - 


User FROM 0UO,INV,TEMP - 


ooo” PWWHERE QUOPART=INVPART = 


Matching fields 


between QUO and INV | 
| ORDER BY 


Matching fields 
between QUO and 
TEMP 


Display QUOPART 
Outout £4 


QUOPART 


NUT 
GENERATOR 
GENERATOR 
WHEEL 
WHEEL 
GEAR 
CAM 
CAM 
BOLT 
BOLT 
BOLT 
BOLT 
BOLT 
NUT 
NUT 
NUT 
WASHER 
WASHER 
WASHER 
WHEEL 
BELT 


r "AND QUOPART=TEMPPART - 
AND TOTORDER < 2 * ONHAND - 


QUOSUPP 


——_ a 


yp Na 


INO 


ONHAND 


400 
1000 
1100 
7500 
5000 
5000 

65000 
65000 
65000 
125000 
125000 
70000 
70000 
110000 
600000 
600000 
600000 
35000 
8500 





2000 


200 
10000 
5000 
S000 
106000 
10000 
15000 
5000 
20000 
6000 
10000 
4000 


2400 
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rm rm rr 


Third Step: Since we no longer need the data in the TEMP table, we can elect to DROP 
(erase) ul. 


User DROP TABLE TEMP 


You will see how all of the preceding can be done in a single query later. Again, think of 
how much more effort would have been required to do this tn a non-SQL/DS environment. 


Summary CREATE TABLE TEMP 
TEMP 


QUO 
First Step: 
es 
INV 


ee 


SELECT FROM QUO. INV, TEMP 





Second Step: 
Output 


Third Step: DROP TABLE TEMP 


aa 





Subqueries 


User 


This ig the main part of 


the query 


This is the subquery 


Display 
Output 


User 


Display 
Output 


Advanced 
Uses of SQL 


When one query is embedded In another, it is called a subquery One reason why SQi is 
so powerful Is that the user can build complex queries by an assembly of many simple 
quenes. 


Subqueries are usually evaluated once during the processing of the overall query, and 
their resulting “answer list’ is substituted directly info the matin query. 


Depending on how the user structures nis subquery. it can operate in a different way 
The following examples show various ways of writing a subquery. 


To fina those quotations for part 134 tn which the price is greater than the minum price 
for that part, we could enter: 








Now to find those quotations for part 105 in which the orice is greater than the average 
unit price for all the pars in our inventory. we enter: 
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Repeating In the previous two examples of subquernes, the subquery was processed once and the 
Subqueries resulting vaiue substituled into the main query. The following example shows a Subquery 
that ts executed repeatedly, once for each row tn the table. 


Let’s find those suppliers whose price for a part exceeds the average price for that pan 
and show the supplier, pan, and price. 


User SELECT QUOSUPP, QUOPART, PRICE - 
The 'X' indicates thal mm a rd 

| | ‘6 —— 
the subquery should be ( SELECT AVG(PRICE) - 
processed for each FROM QUO ~ 
selected row in QUO. ——-» WHERE X.QUOPART = QUOFART ) 
‘X’ is a character string ORDER BY QUOSUPP 


the user creates of 
his own choosing. (é.g. 
'y", ‘Each’, etc.) 


Means “find the aver- 
age price for each 
part we SELECT from 
the QUOTATIONS 


table” 

Display QUOSUPP QUOPART PRICE 

Oulput 51 221 0.30 
51 231 0.10 
53 241 0.08 
53 222 0.25 
53 135 0. 42 
53 124 1.35 
53 125 0.58 
54 134 0.47 
61 105 9.95 
61 221 Q.20 
61 241 0.05 
64 106 4.85 
64 209 19.50 


Looking over these last three examples, you can sée the subtle power of subqueries. 
Within ine basic SELECT..FROM..WHERE structure, the user can concisely direct SQL’ 
DS to do precisely what is needed, just by a slight modification of the query. And it 
doesnt require learning different commands to perform each of tne variations of these 
special operations. 
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Uses of SQL 
Repeating Let’s go back to the example where we wanted to know about those parts on order thal 
Subqueries with were less than twice the balance-on-hand. Our previous sojution involved building a 
Multiple Tables temporary table. 


We can obtain our answer in another way by using a repeating subquery. This technique 
Is shown below. 


Let’s see the paris where the total quantity ordered is less than twice this balance. 
SELECT QUOPART, PNAME, QUOSUPP,PRICE,ONHAND,ONORD - 


FROM INV, QUO X - 
WHERE QUOPART=INVPART - 


User AND 2 * ONHAND > = 
<< (SELECT SUMLONORD) = 

We want to calculate FROM QUO - Py 

the total orders each WHERE X. QUOPART = QUOPART) - 
time we SELECT ORDER BY QUOPART 


another part number 
from the INV table. 


Display QUOPART PNAME QUOSUPP PRICE ONHAND ONORD 
sulpet 106 GEAR 64 4.85 700 0 
106 GEAR 61 4.35 700 300 
124 BOLT 53 1.35 300 500 
124 BOLT 51 4 TM 900 400 
125 BOLT 51 0.55 1000 0 
125 BOLT 53 0.58 1000 0 
134 NUT 53 0.38 900 200 
134 NUT 54 0.47 900 0 
134 NUT 51 0.40 900 500 
171 GENERATOR 54 21.75 500 200 
172 GENERATOR 57 45.15 400 300 
181 WHEEL 64 5.65 1000 400 
182 WHEEL 64 7.05 1100 400 
207 GEAR 64 29.00 7500 2000 
209 CAM 64 19.50 5000 800 
209 CAM 54 18.00 5000 200 
221 BOLT 51 0.30 65000 10000 
221 BOLT 61 0.20 65000 5000 
221 BOLT 54 0.10 65000 5000 
222 BOLT 61 0.20 125000 10000 
222 BOLT 53 0.25 125000 10000 
231 NUT 51 0.10 70000 5000 
231 NUT 54 0.04 70000 15000 
232 NUT 53 0.10 110000 20000 
241 WASHER 53 0.08 600000 6000 
241 WASHER 61 0.05 600000 4000 
241 WASHER 54 0.02 600000 10000 
285 WHEEL 57 21.00 35000 fo) 
295 BELT 57 8.50 8500 2400 


The technique above and the approach using temporary tables are both valid solutions. 
An advantage of the SQL language }s that one can choose the way that feels most 
comfortable. 


The query above used the QUOTATIONS table twice: ance in the main part of the query 
to get the detail information (supplier number, price, quantity ordered). and then again 
in the subquery, to get the total ordered (GSUM(ONORD)) 


Now we're going to show how you can conceptually access a single table to get informa- 
tion from two different rows in the same table. 


Working on Let's display the maximum and minimum prices for each part in our data base, and show 
Two Rows at the corresponding supplier numbers. (The maximum and minimum prices are associated 
a Time with different suppliers, and therefore are in two different rows of the QUOTATIONS table.) 


We're going to imagine that we have two “virtual” copies of the QUOTATIONS table. From 
one of these we're going to get the maximum price and supplier number for each part, 
and from the other, we're going to get the minimum orice and supplier number. 


Just as we did earlier, we'll make up character strings MX and MN and call the two copies 
of the QUO table QUO MX and QUO MN. This will allow us to distinguish between 
similarly named fields from the two tables. 


User SELECT MX.QUOPART,MAX(MX. PRICE) ,MX.QUOSUPP, MIN(MN.PRICE),MN.QUOSUPP - 

FROM QUO MX, QUO MN - 
WHERE MX.QUOPART = MN.QUOPART - 
AND MX.PRICE = (SELECT MAX(PRICE) - 

FROM QUO - 

WHERE QUOPART = MX.QUOPART) - 
AND MN.PRICE = (SELECT MIN(PRICE) - 

FROM QUO - 

WHERE QUOPART = MN.QUOPART) - 
GROUP BY MX.QUOPART,MX.QUOSUPP,MN.QUOSUPP - 
ORDER BY MX.QUOPART 


Display QUOPART MAX(PRICE) QUOSUPP MIN(PRICE) QUOSUPP 
Output 105 9,95 61 7.50 52 
106 4.85 64 4.35 61 
124 1.35 53 1.25 $1 
125 0.58 53 0.55 51 
134 0.47 54 0,38 53 
135 0.42 53 0.39 $1 
171 21.75 54 21.75 54 
172 45.15 57 45.15 57 
181 5.65 64 5.65 64 
182 7.05 64 7.05 64 
205 0.15 52 0.15 52 
206 0.15 52 0.15 52 
207 29.00 64 29.00 64 
209 19.50 64 18.00 54 
221 0.30 51 0.10 54 
222 0.25 53 0.20 61 
231 0.10 51 0.04 54 
232 6.10 53 0.10 53 
241 0.08 53 0.02 54 
285 21.00 57 21.00 87 
295 8.50 $7 8.50 57 


Using this approach, a rather complicated inquiry is simplified by a two-table query. 














SQL/DS can provide your installation with a comprehensive development capability that 
can span a wide range of users and applications. 





An Application The underlying relational data structure and concise interactive language permeate all 
Development Tool aspects of SQL/DS and provide the DP department with a powerful yet easy-to-use 
That is Easy to Use alternative to add to its repertoire of application development tools. 

Improves Produc- For the DP department, the productivity gains obtained can be considerable, either by 
tivity for the DP using SQL directly, or by offloading much of the reporting, analysis, and planning aspects 
Professional and of applications to the user department. On the other hand, end-user departments can 
the End User begin using the data they have long needed. They can gain the benefits from its 


increased availability, getting more of the right data at the right time. 





Allows for Faster From application specification to production operation, the productivity aspects of SQL/ 
Implementation DS affect virtually every phase of development...from the initial discussions with the user 
of New Systems department...to building the data base...to validating the results with prototype queries. 
Cost Effective If you have applications that are constantly changing, have a short life cycle, or involve 
Alternative stand-alone non-integrated data, SQL/DS may offer the best development alternative 


at a lower cost. 





Whatever your current application development approach is, SQL/DS may be the appro- 
priate addition you need to complement your existing development and end-user strate- 
gies in order to satisfy the growing demands of the 80's. 
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DEFECTO PARTS 
VESUVIUS, ONC. 
ATLANTIS co. 
TITANIC PARTS 
EAGLE HARDWARE 
SRYLAB FARTS 
ENTIGHT LID. 


lé& JUSTAMERE LANE, TACOMA WA 

Sle ANCTENT BLVD., POMPEII NY 

8 OCEAN AVE., WASHINGTON DC 

32 SINKING &ST.., ATLANTIC CITY NJ 
be TRANQUILITY PLACE, APOLLO MN 
i26 GRBIT BLYD.. SIDNEY AUSTRALIA 
256 ARTHUR COURT, CAMELOT ENGLAND 



































